Validating an ‘ns’ Simulation Model of the DOCSIS Protocol

The number of households and businesses using HFC cable networks for Internet access is rapidly approaching 20million in the United States. The cable industry has standardized on a single MAC and physical layer standard, the Data Over Cable System Interface Specification (DOCSIS). We have implemented a simulation model of the DOCSIS 1.1/2.0 MAC and physical layer using the ‘ns’ simulation package. In this paper we provide analytic and live network evidence that the simulation model is correct. To demonstrate the model, we provide the results of a brief simulation-based performance evaluation designed to provide insight as to how a best effort VoIP service (e.g., Vonage) performs under varying traffic loads compared to a VoIP service that utilizes DOCSIS QoS mechanisms. Keywords— Simulation, Broadband Access, HFC Cable Networks, TCP Performance A. INTRODUCTION The cable industry has converged to the Data Over Cable System Interface Specification (DOCSIS) as the standard MAC protocol for data over HFC cable networks [1]. The DOCSIS standard was developed by the cable industry’s research consortium, CableLabs [2]. The standard defines the MAC and physical layers for sending data over hybrid fiber coaxial (HFC) cable networks. A multi-system operator (i.e., a cable operator otherwise known as an MSO) operates the cable modem termination system (CMTS) units that interact with cable modems (CMs) deployed at subscriber’s locations. A modern CMTS houses multiple ‘blades’ with each blade supporting one or more HFC domains (1 downstream channel with one or more upstream channels). 6Mhz (or larger) of bandwidth is allocated from the 88-860Mhz spectrum for each downstream channel and upstream channels are allocated from the 5 – 52Mhz frequency range. In the downstream direction, a single sender (the CMTS) transmits to a set of CMs using a data rate ranging from 10Mbps to 50Mbps. IP packets sent downstream are divided into 180 byte MPEG frames. As in a LAN, each CM has a unique MAC address and will receive only frames that are addressed to its MAC address or to the broadcast address. In the upstream direction, multiple senders (CMs) share a channel offering data rates in the range of 5Mbps to 10Mbps. The upstream transmission model is a combination of contentionless shared access using time division multiple access (TDMA) and contentionfree access using a reservation mechanism. IP packets that are sent upstream are encapsulated in a DOCSIS frame and transmitted during assigned slots. If a packet does not fit in the number of contiguous slots that were allocated it is fragmented into multiple frames. Traffic from CMs is classified in terms of service flows. As an example, a configuration that supports telephony would have 4 service flows: two for the upstream and downstream VoIP traffic and two for the upstream and downstream best effort traffic. DOCSIS maps service flows to one of several ATM-like services including best effort, unsolicited grant service (UGS, which is equivalent to ATM’s CBR service), and non-realtime polling (nrtPS, which is equivalent to ATM’s nrtVBR service). As in ATM, different performance guarantees are available for each service. The particular type of service determines how upstream bandwidth is 1 2 allocated to CMs. UGS periodically provides grants to the CM, nrtPS periodically asks the CM if it needs bandwidth, and best effort allocates bandwidth on-demand using a contention-based request mechanism. Prior analysis of the IEEE 802.14 standard, the predecessor to DOCSIS, found that TCP throughput over HFC networks is low primarily due to ACK compression [3]. While assumptions made by the authors (such as high loss rates in the upstream path) are no longer true, our recent results do confirm that DOCSIS induces ACK compression. More recent analysis has been performed using an Opnet model[4]. However most of these studies were limited in scope. Further, since source code for the model is not readily available, the model is of limited use to the research community. In order for the research community to participate in the advancement of this important broadband access technology, a fully functional, validated and documented simulation model is required. In previous work, we presented a preliminary ‘ns’ DOCSIS simulation model that we developed and showed that certain system parameters can significantly impact performance and dynamics of a DOCSIS system [5,6,7]. In this paper we extend our past work by providing a robust validation of the model. We validate the model by comparing simulation results with live network measurements and with analytic results. To demonstrate the model, we explore the use of best effort VoIP services over DOCSIS access networks. Services such as Vonage and AT&T offer VoIP without engaging DOCSIS QoS mechanisms [8,9]. While this conflicts with the cable industry’s direction for telephony, these best effort services offer an inexpensive and popular alternative. The rest of this paper is organized as follows. The next section presents the operation and features of our DOCSIS model. We present an analytic model that captures the upstream behavior of DOCSIS. Then we present the results of a simulation analysis using our ‘ns’ DOCSIS model involving hundreds of active CMs generating a mix of web, streaming, P2P and VoIP traffic. Finally, we provide conclusions and identify future work. 1 A long version of this paper as well as the ‘ns’ simulation code and documentation is available at http://www.cs.clemson.edu/~jmarty/docsis.html 3 B. SUMMARY OF THE SIMULATION MODEL The simulation model implements the DOCSIS architecture defined in [1] with the following restrictions: 1)CMs are limited to a single default best effort service flow and a single UGS or nrtPS flow; 2)the model is limited to one upstream channel for each downstream channel; 3)the model does not support dynamic service provisioning; 4)physical layer impairments are not modeled; 5)the model assumes that the CMTS and the CM clocks are synchronized. Packets sent over the downstream channel are broken into 188 byte MPEG frames each with 4 bytes of header and trailer. The model accounts for physical layer overhead including framing bits and forward error correction data. The downstream channel supports an optional token bucket-based service rate. Each SID service queue is treated in a first come first serve manner. Depending on traffic dynamics, queueing can occur at either the SID queue or the downstream transmission queue. The maximum size of either queue is a simulation parameter. All CMs receive periodic MAP messages from the CMTS that identify future upstream scheduling opportunities over the next MAP time. If provisioned with a periodic grant, a CM can send at its next data grant opportunity. For best effort traffic, a CM must request bandwidth from the CMTS using a contention-based mechansim. When a CM is ready to transmit a request frame, it selects a random number within its backoff window which is determined by the backoff range value. While this value is sent to the CM in each MAP, our implementation never alters the statically configured value. After a CM transmits the request, if the next MAP does not contain either a grant or a grant pending indication from the CMTS, the CM assumes a collision occurs and increases the backoff window by a factor of two. The contention request cycle continues until it succeeds or it has tried a total of 16 times in which case the packet is dropped. A CM can request bandwidth sufficient to transport multiple IP packets in a single DOCSIS frame by issuing a concatenated bandwidth request. A further performance improvement, one which minimizes the frequency of contention-based bandwidth requests, is for a CM to piggyback a request for bandwidth on an upstream data frame. If a CM receives a grant for a smaller number of slots than were requested, the CM must fragment the data to fit into the assigned slots. Figure 1 illustrates the upstream transmission of a 1500 byte IP datagram from a TCP source to a sink located outside the HFC network. Time progresses in the downwards direction. We assume collisions do not occur. The figure depicts an example configuration with a MAP size of 64 slots, an upstream channel capacity of 5.12Mbps and 5 ticks per slot. 85 slots are required to transport a 1500 byte IP packet. The small dark square box positioned at the beginning each MAP time represents the transmission of the MAP message in the downstream direction. Our model sends a MAP message at the beginning of each MAP time. Each MAP describes the slot assignments for the next MAP time. The IP packet arrives at the CM during the j’th MAP at time T-0. The CM sends the bandwidth request message at time T-1 and receives the data grant at time T-2. The grant is located in the third MAP time. The CM sends the frame at time T-3 and is received by the CMTS at time T-4. The time between T-3 and T-0 is the access delay which represents the total time a packet is delayed over the DOCSIS network not including transmission and propagation time experienced by the data packet (we also refer to this delay as the ). Packets that arrive at a CM that is waiting for bandwidth to send packets that have already arrived will be queued. The size of the upstream CM queue is a configuration parameter. request t Figure 1. Upstream transmission scenario The bandwidth scheduler runs at the CMTS node. It executes on every tick of a timer that is set to the MAP time frequency. The algorithm examines all existing requests for bandwidth and implements an earliest deadline first scheduling policy. All UGS service requests are scheduled and whatever bandwidth is left over is shared by best effort requests on a first-come-first-served basis. The scheduler supports dynamic MAP times by allowing a MAP to specify grants up to a configured maximum (known as the MAP lookahead). The scheduler will only do this if it can meet all QoS requirements. For example, a system with a configured MAP time of 64 slots will generate a MAP containing 100 slots when a 1500 byte IP packet is transmitted (85 slots for the IP packet, 3 slots for management frames and 12 slots for contention requests). When a MAP has been stretched to fit a bandwidth request, the scheduler always adds the configured number of management and contention slots to the MAP. The scheduler by default will assign all unused slots to be available for contention requests (this behavior can be changed). TCP Source CM CMTS TCP/Sink